fix(objectql): the boot-time governance audit resolves a SCOPED metadata plane the way a request does - #16610

Fixes #15252

The C4 cell #14423's ruling left open: let the boot-time, non-request-scoped
action-governance audit obtain the scoped metadata service the way a request
would.

What was broken

ObjectQLPlugin.runGovernanceInventory acquired its metadata plane with
ctx.getService('metadata'). That accessor reads only the two synchronous
service maps — the kernel's own services, and PluginLoader.getServiceInstance
over serviceInstances. A ServiceLifecycle.SCOPED registration mints its
instances into scopedServices, keyed by scope id, so the call threw
Service 'metadata' is async - use await before loadMany, loadManyKeyed,
loadDiagnosed or load could run. The wiring swallowed the throw into "no
metadata plane at all", and the ADR-0110 D5 inventory reported that scope's
action declarations as absent — silently, because an empty declaration set is
indistinguishable from a plane that holds nothing. On such a kernel a handler the
router dispatches was reported as "registered handler with NO declaration …
REFUSED at dispatch".

The router never had that gap: HttpDispatcher.resolveService asks
defaultKernel.getServiceAsync(name, scopeId) first, with the request's
environment id, and only then falls back to the synchronous accessors.

The fix, and why this shape

The card offered two shapes and did not choose: an awaited resolution, or an
injected reader the plugin resolves once. The deciding question it names is
which one makes the audit read the same instance the router resolves through.

Taken: the awaited resolution. ObjectQLPlugin.resolveGovernanceMetadataService
mirrors the router's own order — ctx.getServiceScoped('metadata', environmentId)
first, then the synchronous lookup. Both ctx.getServiceScoped(name, scopeId) and
the dispatcher's getServiceAsync(name, scopeId) land on
PluginLoader.getService, which caches per scope, so the audit holds the very
object the router dispatches from — asserted by toBe identity in the pin, not
by equality.

Why the injected reader was not taken. Resolving once and holding the result
is the wrong lifecycle for this seam on two counts. runGovernanceInventory runs
at kernel:ready and again on every metadata:reloaded, so a reader captured
earlier freezes the identity the audit reads while the kernel's own can move
(ObjectKernel.clearScope releases a scope's instances). And resolving before the
scope exists mints an instance beside the request path rather than the one on
it — precisely the identity failure the card is about. The awaited resolution asks
the same registry, at the same moment, that the router asks.

The pin, and its ablation

The card names its own acceptance bar: "Pin with a fixture that composes a scoped
metadata service and asserts the audit reports its declarations; ablation: the
synchronous read, the fixture goes red."

packages/objectql/src/plugin-governance-scoped-metadata.test.ts composes a real
ObjectKernel with a ServiceLifecycle.SCOPED metadata factory over a real
MetadataManager + DatabaseLoader, captures the kernel's real
PluginContext (so the accessor under test is the real one, not a transcription),
and runs the audit. Five cases: the declaration reported by name, the accusation
cleared, the instance identity, a regression guard for the statically registered
plane every shipped composition uses, and the boundary that remains.

Every assertion reads the audit's output. The pre-fix failure is silent, so
"no error was thrown" is exactly the state that already existed and pins nothing.

Ablation — the synchronous read restored (packages/objectql/src/plugin.ts
restored to the branch point, which is the pre-fix spelling; on-disk blob
proven equal to that commit's blob, marker hits 1 → 0, synchronous-read hits
0 → 1, then rebuilt):

mutated  (synchronous read)  vitest exit 1  —  Tests  3 failed | 2 passed (5)
             × REPORTS a declaration that exists only in the scoped plane, by name
             × does NOT accuse a handler whose only declaration lives in the scoped plane
             × reads the SAME instance the router resolves through, and mints no second one
restored (the fix)           vitest exit 0  —  Tests  5 passed (5)

The two cases that stay green under the ablation are the two that must: the
static-plane regression guard and the declared boundary. A "fix" that merely
silenced the audit would flip those too.

One measurement worth recording rather than smoothing over:
scripts/ablation-dist-preflight.mjs --absent exited 1 on the mutate leg,
reporting the marker surviving in dist/index.d.ts and dist/index.d.mts while
both executable artifacts (dist/index.js, dist/index.mjs) were correctly free
of it. That is the marker-uniqueness false red the script's own header documents:
the surviving hits are the prose in action-governance.ts's docblock, which names
ObjectQLPlugin.resolveGovernanceMetadataService and was not part of the
mutation. It does not bear on the ablation's colour either way — this fixture
resolves its subject from source (./plugin.js, same package), never through
dist/ — and the load-bearing proof is the on-disk blob identity above.

Recorded facts re-derived, not inherited

• No shipped composition walks into C4 — confirmed on this tree. The only
  ServiceLifecycle.SCOPED registration outside tests is in
  packages/core/examples/kernel-features-example.ts, and metadata is
  registered as a static instance at packages/metadata/src/plugin.ts:374. The
  fixture therefore composes the scoped case deliberately.
• The failure sits upstream of [finding] Two residual audit ↔ router asymmetries after #14123: the audit's third source is loadMany while the router's is load by name, and unboundDeclarations still reads two sources where the undeclared-handler half now reads three #14423's fix — still true after fix(metadata,objectql): the action audit reads the store key and asks the plane by name, and listNames gains loadMany fault parity #15378 landed.
  loadManyKeyed, loadDiagnosed and the by-name rung are all wired off the one
  getService call, inside the one try that swallowed its throw.
• The card's own re-check grep is stale, and the defect is not. The literal
  getService('metadata') no longer appears as a live call because the call site
  carries a type argument. The live acquisition was at
  packages/objectql/src/plugin.ts:2517 on the branch point, inside
  runGovernanceInventory. Premise still valid; only the grep had rotted.

Verification

• pnpm --filter @objectstack/objectql test — 285 files, 4806 tests, all pass.
• pnpm --filter @objectstack/objectql typecheck — pass; the test-typecheck debt
  ledger is unmoved (44 files / 242 errors / 69 pinned signatures).
• Gates derived with node scripts/pm/dispatch-gates.mjs --commands from the
  actual change set and reconciled with --ran: 65 derived, 65 run, 0
  NOT-MEASURED, 0 UNRUN. 63 green. Two answered PREREQUISITE NOT MET (exit 3,
  measured nothing, not a finding): check:dual-build-cjs-loads and
  check:type-check-debt both require a whole-workspace build that CI's lint job
  performs before the step. check:engine-split-ratio first refused on the
  shallow clone (exit 2); after git fetch --shallow-since it answered (98.1%).
• check:engine-double-contract asked for the fixture's findOne double to be
  recorded and was answered with its own --write; the row landed in the
  pinned ledger, not the shrink-only baseline.

Acceptance notes

• Out of scope, but this PR makes it stale — please route it.
  packages/runtime/src/action-governance-scope-divergence.test.ts's C4 case is
  still green and its assertions stay true (they exercise the kernel's raw
  synchronous accessor, not the plugin), but its prose now says the opposite of
  this tree: "the audit's lookup cannot see a scoped instance at all, and
  plugin.ts swallows the throw", "the assertions below pin the BOUNDARY", and
  "reaching a request-scoped instance from there is a different change with its
  own product decision, tracked on its own card" — that card is this one. Left
  untouched deliberately: the dispatch fenced this PR to
  packages/objectql/src/plugin.ts / action-governance.ts plus a fixture pin,
  with "stop on breach". A reader who trusts that docblock could revert this
  change, so it wants a follow-up in the runtime lane. The canonical statement of
  what is now closed and what remains lives in action-governance.ts's updated
  docblock.
• The remaining boundary is stated in both docblocks and pinned as a case: a
  kernel serving several environments at once declares no single environmentId,
  so a boot-time audit has no scope to name. Auditing per environment is a
  different inventory with a different lifecycle.
• Clause-② re-derived from the actual diff: no. Nothing exported moves — the
  new method is private on an already-exported class — and no accept set widens.
  Changeset disposition derived from the act: a behaviour fix in a released
  package, so a patch changeset for @objectstack/objectql, not
  skip-changeset.

Generated by Claude Code